Automazione di Test di Sistemi Embedded. Sintesi

Транскрипт

1 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: telefono: [email protected] Anno Accademico Appello di Laurea 15 Luglio 2010

2 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

3 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 dif- 2

4 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 pro- 3

5 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

6 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

7 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

8 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 per- 7

9 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