Automazione di Test di Sistemi Embedded Sintesi

UNIVERSITÀ DEGLI STUDI DI MILANO - BICOCCA
Facoltà di Scienze Matematiche, Fisiche e Naturali
Dipartimento di Informatica Sistemistica e Comunicazione
Corso di Laurea Magistrale in Informatica
Automazione di Test di Sistemi Embedded
Sintesi
Relatore:
Prof. Mauro PEZZE’
Correlatori:
Lorena SIMONI
Giuseppe GORGOGLIONE
Relazione della prova finale di:
Carmine Carella
matricola: 055465
telefono: +39 3294140513
e-mail: [email protected]
Anno Accademico 2009-2010
Appello di Laurea 15 Luglio 2010
Introduzione
I sistemi embedded sono sistemi di elaborazione progettati per una determinata applicazione e supportati da una piattaforma hardware dedicata. La
loro diffusione è inarrestabile, le analisi di mercato mostrano che sono ormai
presenti in ogni apparato sia in modo evidente, il cellulare e i PDA né sono
un esempio, sia in modo trasparente come accade per gli elettrodomestici o
le automobili.
Questi sistemi sono una combinazione di hardware e software, tra loro
fortemente integrati. Dal punto di vista hardware generalmente un sistema
embedded è costituito da soluzioni single-chip che incapsulano molte funzionalità di un normale computer su un singolo dispositivo. Il software può
essere molto diversificato, in base alla potenza computazionale dell’hardware. Nei sistemi con scarse risorse viene sviluppato, di solito, software
ad-hoc dimensionato alla capacità di calcolo, invece nei sistemi che adottano hardware di classe superiore è possibile ospitare un sistema operativo
e applicazioni, con interfacce utente evolute.
Negli ultimi anni tali sistemi sono diventati molto complessi, ed il software contenuto in essi è diventato un elemento chiave, arrivando ad essere
perfino più importante dell’hardware stesso, in quanto è la componente che
permette di aumentare le funzionalità del sistema e di ottenere un minimo
di flessibilità, in questi sistemi caratterizzati dall’essere poco versatili.
Conseguenza diretta dell’evoluzione e della criticità del software, è la
crescita della complessità e dell’importanza del processo di testing. Il testing è un processo costituito da diverse attività durante il ciclo di sviluppo
del software e ha lo scopo di identificare e rimuovere i difetti per migliorare la qualità. L’automazione del testing attraverso l’utilizzo di strumenti
permette di aumentare l’efficacia e ridurre il costo di questo processo che
spesso è più della metà del costo totale dello sviluppo software. I sistemi
embedded sono sempre più utilizzati in ambiti critici come quello avionico
e aerospaziale in cui la presenza di un difetto all’interno del software può
portare ad un fallimento del sistema e conseguentemente, compromettere la
vita umana e provocare ingenti perdite economiche. Rispetto ad altri ambiti, quello embedded introduce requisiti di criticità nel sistema che hanno
bisogno di maggiore attenzione. Il testing è uno degli elementi per garantire
la qualità del sistema.
Problema e Stato dell’arte
L’ambito embedded introduce nuove sfide e problemi da affrontare. Esso
ha delle caratteristiche peculiari che influenzano tutte le attività del processo di sviluppo. Il testing non è un’eccezione. Questo dominio estremamente complesso ha: un processo di sviluppo che considera sia la parte
1
hardware che la parte software del sistema; specifiche complesse; vincoli
platform-dependent (cpu, memoria, consumo energetico, periferiche); requisiti di qualità molto stringenti; costi contenuti e vincoli di tempo che
specificano un time-to-market molto breve.
Inoltre, anche la caratteristica di specificità dei sistemi embedded influenza il testing. Ogni singolo settore applicativo richiede di prendere in
considerazione aspetti talmente peculiari da rendere difficile l’identificazione
di tecniche e strumenti di valenza davvero generale. La diretta conseguenza è lo sviluppo di approcci ad hoc. Ancora, l’utilizzo di uno strumento
di automazione è vincolato da una notevole personalizzazione in cui vengono eseguiti adattamenti di basso livello all’architettura di uno specifico
processore per rendere funzionante lo strumento. Data la complessità della personalizzazione, essa può concludersi con un successo o un insuccesso
influenzando la raccolta e l’analisi dei risultati per valutare e migliorare la
qualità.
La letteratura sul testing del software, contiene innumerevoli metodologie, tecniche e strumenti che supportano il processo di testing di software
tradizionale, ma esiste ancora poco per il testing di software embedded.
Negli ultimi anni sono aumentati i lavoro accademici e industriali, ma questa è un’area di ricerca ancora da esplorare. Alcune domande attendono
una risposta più precisa. Tra queste, quali sono i punti chiave del testing embedded?, in cosa differisce esattamente il testing embedded dal testing
tradizionale? quali sono le soluzioni e gli strumenti da applicare?. Ad oggi,
il testing di software di sistemi embedded è stato formalizzato solamente
attraverso la creazione di tecniche e strumenti proprietari (molto costosi) e
metodologie aziendali interne e di conseguenza non utilizzabili. Non esiste
di fatto ancora un approccio generale, che inglobi al suo interno strumenti
aventi licenze gratuite, e che raccolga pratiche comuni di test, attraverso le
quali sia possibile garantire uno sviluppo software di qualità.
L’ambiente di sviluppo del software embedded è diverso dall’ambiente di
esecuzione, ovvero il software viene sviluppato su una macchina con risorse
computazionali maggiori e architettura differente detta host, rispetto alla
macchina detta target che coincide proprio con l’architettura embedded per
la quale il software viene creato e sulla quale deve essere eseguito. Questa
suddivisione porta ad avere due ambienti per il testing in cui applicare tecniche diverse per valutare requisiti di qualità differenti. Questi due ambienti,
nel testing di software tradizionale, non esistono in quanto l’ambiente utilizzato per lo sviluppo è anche quello di esecuzione. Questa differenziazione
porta al problema di definire la strategia di testing: quale test deve essere
eseguito sull’ambiente host e quale sull’ambiente target? Un certo requisito
di qualità deve essere valutato nell’ambiente giusto. Naturalmente questo
andrà ad influenzare le tecniche di testing da utilizzare sia nell’ambiente
host che nell’ambiente target.
Il testing del software embedded nell’ambiente host, non evidenzia dif2
ferenze con il testing di software tradizionale. Nell’ambiente host vengono
verificate le caratteristiche funzionali del software in esecuzione in un ambiente che simula la piattaforma reale, attraverso le tecniche di testing
utilizzate anche nel software tradizionale: test di unità e test d’integrazione.
Le maggiori differenze emergono con il testing nell’ambiente target che
è effettuato in quanto bisogna considerare le dipendenze del software con
l’hardware specifico per verificare che il codice operi correttamente sulla piattaforma sotto condizioni realistiche. Specialmente per i sistemi embedded
è importante sviluppare tecniche e strumenti di testing per rilevare difetti nell’interazione tra hardware e software. In quest’ambiente devono essere
verificate le caratteristiche funzionali del software, questa volta in esecuzione
sulla piattaforma reale, dove le misure sono più affidabili, e le caratteristiche
non funzionali che possono essere valutate soltanto in quest’ambiente con
l’effettiva interazione del software con l’hardware dedicato.
Obiettivi della tesi
La prevalenza di approcci poco concreti nella scarsa letteratura sul testing di
software embedded, e la presenza di approcci ad-hoc e proprietari in ambito
industriale, evidenzia la mancanza di tecniche e strumenti utilizzabili in
contesti differenti. Questo aumenta la necessità di un approccio generale
attraverso il quale sia possibile garantire uno sviluppo software di qualità.
La tesi fornisce un contributo in questa direzione, per superare i problemi
di specificità del testing in questo dominio, attraverso la sperimentazione in
una realtà industriale complessa e affermata, di tecniche e strumenti per il
testing di caratteristiche funzionali e non funzionali di software embedded.
La tesi studia alcuni problemi di qualità specifici e propone delle tecniche
di testing che possono essere applicate nell’ambiente target per valutare
classi di difetti rilevanti nei sistemi embedded.
Inoltre, descrive l’adattamento e l’utilizzo di strumenti di automazione
per applicare le tecniche, affrontando la scelta, in base a caratteristiche
derivate dai vincoli imposti dall’ambiente sperimentale, la personalizzazione
e l’analisi dei risultati.
I risultati ottenuti dal lavoro di tesi possono essere riassunti come:
• un insieme di informazioni sulla personalizzazione degli strumenti per
la piattaforma ARM. Il lavoro svolto, può essere un’utile linea guida
per personalizzare gli stessi strumenti su altre architetture.
• un insieme di informazioni per la comunità open-source sul funzionamento degli strumenti e sulla presenza di problemi da risolvere per
migliorare l’utilizzo sull’architettura specifica.
• un insieme di risultati sperimentali, che convalidano le tecniche e gli
strumenti di testing proposti. Il lavoro di tesi ha migliorato il pro3
cesso di testing utilizzato nell’ambiente sperimentale, aumentandone
il perimetro, attraverso l’individuazione di aree di qualità non ancora
esplorate e introducendo, per la valutazione di queste, strumenti di
automazione che riduco i costi e i tempi del processo.
Ambiente Sperimentale
L’ambiente sperimentale della tesi è quello della divisione Automotive di
STMicroelectronics (STM), la quale ha ideato una nuova famiglia di Systemon-Chip dal nome Cartesio con un alto livello di integrazione di device su
un singolo chip. Il core è costituito dal microcontrollore ARM che permette il supporto per un vasto insieme di periferiche e interfacce di I/O.
Comprende un GPS engine che lo rende un prodotto ideale per navigatori
satellitari e per l’infotainment. Oltre al core viene effettuato lo sviluppo di
board sperimentali che comprendono tutti i dispositivi e le interfacce con le
quali il chip può interagire. La componente software è costituita dal porting del sistema operativo Linux per la piattaforma target, Baseport (BSP),
che comprende principalmente lo sviluppo dei device driver necessari per
la gestione dell’hardware specifico. Tutto questo costituisce un ambiente
di sperimentazione del chip completo e funzionante utile per mostrare le
funzionalità offerte ai committenti.
Il processo di testing del BSP Linux era inizialmente costituito da test
per la verifica del corretto interfacciamento del software con i device, principalmente test funzionali per le periferiche supportate dalla piattaforma.
Con il lavoro di tesi sono state introdotte tecniche di test e strumenti di
automazione per la valutazione di altre classi di problemi.
Le tecniche di test individuate sono state applicate con l’obiettivo di valutare la qualità del codice platform-dependent. Ovvero dell’intero sistema
operativo Linux l’attenzione del processo di testing è posta sull’area dei device driver, sviluppati per la gestione delle componenti hardware specifiche.
Tecniche e approcci per il test
Il processo di sviluppo di un sistema embedded considera le peculiarità sia
dell’hardware che del software. Il testing, a sua volta, in una prima fase
viene svolto separatamente per entrambe le componenti, e in una seconda
fase si focalizza sulla verifica dell’interazione tra l’hardware e il software. La
forte relazione tra queste due componenti del sistema embedded, in aggiunta
alla presenza di vincoli real-time, rende pressoché impossibile sviluppare e
testare il software indipendentemente dall’hardware su cui dovrà essere eseguito. Di qui la necessità del testing nell’ambiente target. Nell’ambito del
progetto Cartesio, sono stati sperimentati approcci e tecniche per il testing
in ambiente target, utili all’identificazione di classi di problemi di maggiore
4
importanza in ambito embedded, attraverso l’utilizzo di strumenti di automazione opportunamente selezionati, in base a diversi criteri individuati
nell’ambiente sperimentale. Per ogni strumento è descritta in modo approfondito la personalizzazione, e in caso positivo l’applicazione e l’analisi dei
risultati. Nell’ambiente target, le tecniche di testing sperimentate sono le
seguenti.
Test di copertura. L’analisi di copertura del codice per la verifica dell’efficacia dei test funzionali esistenti.
Prestazioni del codice. Il profiling (function tracing) per la valutazione
della durata delle funzioni nel processo di boot.
Uso e gestione della memoria. Verifica dell’utilizzo della memoria da
parte del software alla ricerca di problemi di memory leakage;
Prestazioni di I/O su dispositivi a blocchi. Verifica delle prestazioni
delle operazioni di I/O (lettura, scrittura) sui dispositivi a blocchi,
disponibili sulla piattaforma target.
L’analisi di copertura ha l’obiettivo di valutare l’efficacia dei test funzionali
esistenti, in termini di quantità di copertura del kernel, identificando il cosiddetto dead code dei device driver platform-dependent, il codice che non viene
esercitato durante l’esecuzione dei test. I risultati sono utili alla creazione
di casi di test addizionali per esercitare il codice, quindi incrementare la
copertura dello stesso e anche il livello di qualità dei device driver platformspecific sviluppati. Lo strumento scelto è Gcov. Gcov è un framework per
l’analisi di copertura fornito dal compilatore Gnu Gcc.
Il function tracing è una tecnica di profiling utilizzata nel caso specifico
per valutare le prestazioni delle funzioni del kernel eseguite nella fase di boot
del sistema. L’obiettivo è individuare le aree del processo di boot con i maggiori problemi di prestazioni, in particolare identificare le funzioni relative
alla parte di codice platform-dependent eseguite nella fase iniziale del kernel,
per poter intervenire e migliorare i tempi di boot, requisito importante in
ambito embedded. Lo strumento utilizzato è il Function Duration Tracer
che si basa sul framework di tracing di Linux, Ftrace.
Il memory leakage è il principale difetto della classe degli aging-related
bugs, relativo all’uso non corretto della memoria che provoca fallimenti del
sistema. La causa principale di questi difetti è legata a errori di programmazione. Nei sistemi embedded, la limitata quantità di memoria fisica
disponibile e il fallimento del sistema, che può avere conseguenze catastrofiche, rendono il memory leakage un problema su cui soffermarsi maggiormente in quest’ambito rispetto ad altri. Lo strumento utilizzato è kmemleak
per la rilevazione nello spazio del kernel.
La valutazione delle prestazioni di I/O (operazioni di lettura e scrittura)
sui dispositivi a blocchi, periferiche con tecnologia a stato solido (Flash)
5
utilizzate come supporti di memorizzazione di massa nei sistemi embedded,
ha l’obiettivo di individuare possibili problemi di efficienza nei relativi device driver, misurando le velocità di trasferimento dei dati. Lo strumento
utilizzato in questo caso è IOzone.
Risultati
Per lo strumento di analisi di copertura, Gcov, la personalizzazione ha impedito l’utilizzo e la raccolta dei dati sulla copertura. In alternativa è stata
effettuata un’analisi sulle cause, che ha portato alla scoperta di un bug relativo alla parte platform dependent ARM del compilatore Gcc, che esclude un
problema nell’architettura stessa dello strumento. Le informazioni ottenute
sono state pubblicate e inserite su Bugzilla Gcc, affinché i responsabili dello
sviluppo del compilatore possano risolvere il problema e permettere l’utilizzo
di Gcov anche sui sistemi embedded con architettura ARM.
Il Function Duration Tracer, tra tutti gli strumenti, ha una personalizzazione che è la più difficile. Il risultato ottenuto è stato soddisfacente.
Con i dati raccolti, infatti, abbiamo scoperto che la fase di boot del BSP
kernel, può essere ottimizzata escludendo in fase di produzione del prodotto
l’inizializzazione dei driver della porta seriale, un device che è principalmente
utilizzato in fase di produzione per sviluppo, testing e debugging. Inoltre il
lavoro è un contributo valido per l’integrazione diretta dello strumento nel
framework Ftrace nelle future versioni del kernel e ha permesso di aggiungere
al BSP il supporto per il function tracing.
Kmemleak per la rilevazione dei memory leakage nel kernel, non ha avuto
nessun problema per quanto riguarda la personalizzazione. Per mostrare
l’utilità dello strumento abbiamo studiato e individuato i principali errori di
programmazione che possono essere commessi nello sviluppo di un driver e
che causano difetti di memory leak. L’applicazione dello strumento si basa
sulla rilevazione di memory leak causati dagli errori identificati.
Per Iozone, utile alla valutazione delle prestazioni di I/O, la personalizzazione è molto semplice. Lo strumento è stato utilizzato per verificare il
miglioramento di prestazioni dei device driver tra release successive di sviluppo. In particolare è mostrata l’applicazione su una versione migliorata del
driver MMC (MultiMedia Card).
Organizzazione Tesi
Il capitolo 1, è una breve introduzione al mondo dei sistemi embedded, presentandone le caratteristiche, fortemente condizionate dal settore applicativo, per poi delineare le principali differenze con i sistemi desktop e gli aspetti
basilari da considerare nella progettazione. Saranno presentati, inoltre, alcuni dati di mercato che testimoniano la crescita del settore embedded nel
6
mercato globale, e in particolare il progresso che ha avuto in questo ambito
lo sviluppo del software ed il suo utilizzo nei sistemi operativi open source,
come Linux. In seguito, sarà presentata una delle principali architetture
hardware e le caratteristiche del software utilizzato nei sistemi embedded.
La parte finale del capitolo mostra le peculiarità, l’architettura e i principi
di sviluppo dei sistemi Linux embedded.
Il capitolo 2, introduce inizialmente le fasi del processo di testing dei
sistemi embedded, focalizzandosi poi sulla fase di prototipazione e sul testing
della componente software. Successivamente, delinea le differenze con il
testing di software tradizionale. Vengono approfondite le tecniche di test
che possono essere applicate nell’ambiente target. Vengono poi introdotti i
livelli software di un sistema embedded, per identificare su quale concentrare
maggiormente il controllo di qualità nel porting di un sistema operativo.
Infine, viene descritta l’automazione del testing e la personalizzazione degli
strumenti.
Nel capitolo 3 è descritto l’ambiente sperimentale di STMicroelectronics. Inizialmente viene introdotto l’ambito automotive e il progetto Cartesio. Successivamente viene descritto lo sviluppo del sistema embedded, approfondendo l’ambiente utilizzato, e la componente hardware e software.
Viene descritto, poi, il processo di testing e le tecniche adottate. Successivamente vengono delineati i punti di miglioramento del processo di testing,
tra cui copertura di nuove classi di problemi e aumento dell’automazione.
Infine sono mostrati i criteri utilizzati per la scelta degli strumenti, utili per
effettuare il testing delle classi di problemi individuate.
Il capitolo 4 è dedicato all’analisi dell’efficacia del test. Dopo una breve
introduzione al code coverage, vengono descritti gli obiettivi dell’analisi di
copertura nell’ambiente sperimentale e la scelta dello strumento. Infine viene
fornita una descrizione approfondita di Gcov e della personalizzazione per
l’architettura ARM.
Il capitolo 5 è dedicato alla valutazione delle prestazioni del codice nella fase di boot del kernel. Vengono descritti gli obiettivi nell’ambiente
sperimentale e la scelta dello strumento. Successivamente viene introdotto il framework Ftrace e descritto in modo approfondito il Function Graph
Tracer, attraverso la personalizzazione per l’architettura ARM, l’utilizzo e
l’analisi dei risultati sperimentali.
Nel capitolo 6 viene inizialmente introdotto il software aging, e poi presentato il problema del memory leakage e le sue conseguenze. Successivamente, viene descritta la scelta dello strumento e in modo dettagliato il
Kernel Memory Leak Detector (Kmemleak). Infine vengono analizzati gli
errori, causa di memory leakage, che possono essere commessi nello sviluppo
dei device driver e la rilevazione di questi da parte di Kmemleak.
Il capitolo 7 è dedicato alla valutazione delle prestazioni di I/O sui dispositivi a blocchi. Vengono presentati gli obiettivi nell’ambiente sperimentale e
la scelta dello strumento. Successivamente viene descritto IOzone e la per7
sonalizzazione per l’architettura ARM. Infine viene descritta l’applicazione
per valutare un driver specifico e l’analisi dei risultati sperimentali.
Infine l’appendice A, descrive in modo approfondito il processo di boot
del kernel, focalizzandosi però sulla parte platform-dependent dell’architettura Cartesio. Questa appendice è di supporto in modo principale per il
capitolo 6, ma anche per approfondire aspetti citati in altri punti della tesi.
8