Sei sulla pagina 1di 7

CP pensareprogettareprogrammare n.

146 Maggio 2005

Quando serv` un debugger su Marte


di Marco Aldrovandi
In questo articolo si descrive il celebre problema software accaduto alla sonda Pathn` ` der atterrata su Marte nel 1997. Cio che e accaduto ad un computer distante milioni ` di chilometri dalla Terra puo suggerire utili riessioni anche ai programmatori Terrestri

Marco Aldrovandi ` E laureato in Ingegneria Elettronica. Attualmente si occupa di applicazioni safety critical per il settore ferroviario .

pubblicato su WWW.INFOMEDIA.IT stampa digitale da Lulu Enterprises Inc. stores.lulu.com/infomedia


Infomedia
` Infomedia e limpresa editoriale che da quasi venti anni ha raccolto la voce dei programmatori, dei sistemisti, dei professionisti, degli studenti, dei ricercatori e dei professori dinformatica italiani. Sono pi` di 800 gli autori che hanno realizzato per le teu state Computer Programming, Dev, Login, Visual Basic Journal e Java Journal, molte migliaia di articoli tecnici, presentazioni di prodotti, tecnologie, protocolli, strumenti di lavoro, tecniche di sviluppo e semplici trucchi e stratagemmi. Oltre 6 milioni di copie distribuite, trentamila pagine stampate, fanno di questa impresa la pi` grande ed u inuente realt` delleditoria specializzata nel campo della a programmazione e della sistemistica. In tutti questi anni le riviste Infomedia hanno vissuto della passione di quanti vedono nella programmazione non solo la propria professione ma unattivit` vitale e un vero a divertimento. ` Nel 2009, Infomedia e cambiata radicalmente adottando ` un nuovo modello aziendale ed editoriale e si e organizzata attorno ad una idea di Impresa Sociale di Comunit` , a partecipata da programmatori e sistemisti, separando le attivit` di gestione dellinformazione gestite da un board a comunitario professionale e quelle di produzione gesti` te da una impresa strumentale. Questo assetto e in linea con le migliori esperienze internazionali e rende Infomedia ancora di pi` parte della Comunit` nazionale degli u a sviluppatori di software. ` Infomedia e media-partner di manifestazioni ed eventi in ambito informatico, collabora con molti dei pi` imporu tanti editori informatici italiani come partner editoriale e fornitore di servizi di localizzazione in italiano di testi in lingua inglese.

Limpaginazione automatica di questa rivista e realizzata al ` 100% con strumenti Open Source usando OpenOffice, Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp, Python e BASH

For copyright information about the contents of Computer Programming, please see the section Copyright at the end of each article if exists, otherwise ask authors. Infomedia contents is 2005 Infomedia and released as Creative Commons 2.5 BY-NC-ND. Turing Club content is 2005 Turing Club released as Creative Commons 2.5 BY-ND. Le informazioni di copyright sul contenuto di Computer Programming sono riportate nella sezione Copyright alla ne di ciascun articolo o vanno richieste direttamente agli autori. Il contenuto Infomedia e 2005 Infome` dia e rilasciato con Licenza Creative Commons 2.5 BYNC-ND. Il contenuto Turing Club e 2005 Turing Club ` e rilasciato con Licenza Creative Commons 2.5 BY-ND. Si applicano tutte le norme di tutela dei marchi e dei segni distintivi. ` E in ogni caso ammessa la riproduzione parziale o totale dei testi e delle immagini per scopo didattico purch e vengano integralmente citati gli autori e la completa identicazione della testata. Manoscritti e foto originali, anche se non pubblicati, non si restituiscono. Contenuto pubblicitario inferiore al 45%. La biograa dellautore riportata nellarticolo e sul sito www.infomedia.it e di norma quella disponibi` le nella stampa dellarticolo o aggiornata a cura dellautore stesso. Per aggiornarla scrivere a info@infomedia.it o farlo in autonomia allindirizzo http://mags.programmers.net/moduli/biograa

primo piano

Quando serv un debugger su Marte


In questo articolo si descrive il celebre problema software accaduto alla sonda Pathfinder atterrata su Marte nel 1997. Ci che accaduto ad un computer distante milioni di chilometri dalla Terra pu suggerire utili riflessioni anche ai programmatori "Terrestri"
di Marco Aldrovandi

l 4 Luglio 1997 la sonda FIGURA 1 La sonda Pathfinder Automatica Pathfinder tocc il suolo di Marte dopo un viaggio durato 7 mesi. Latterraggio non present problemi, grazie al sistema di airbags che attut lo shock dellurto. Appena atterrata, la sonda inizi subito a trasmettere dati alle stazioni di ricezione sulla lontana Terra, tra cui una serie di eccezionali immagini del paesaggio Marziano. Quando inizi la raccolta dei dati metereologici per uno strano inconveniente inizi a portare preoccupazione su una missione che, fino a quel momento, si era svolta in modo assolutamente perfetto: periodicamente la sonda interrompeva linvio dei dati, per poi riprendere successivamente. Le prime indagini portarono ad attribuire la causa ad un Architettura della sonda reset periodico del computer di bordo. Non riuscendo a raccogliere dalla sonda su Marte sufficienti informaIn Figura 1 riportato un disegno della sonda zioni per risalire alla causa dellinconveniente, non Pathfinder; il software che ne assicurava il funzionarimase altra via che tentare di ricreare il problema nel mento aveva molto in comune con quello installato computer della sonda gemella presente, proprio a quenelle macchine automatiche presenti nelle nostre fabsto scopo, al Jet Propulsion Laboratory (JPL): la sonda briche: era cio un software real-time e multitasking. Si fu sottoposta a stimoli esterni il pi possibile simili a dice che unapplicazione real-time quando, in corriquelli a cui era sottoposta la sua gemella su Marte e spondenza di un particolare stimolo esterno, essa vennero registrati tutti i possibili dati relativi al funrisponder in un tempo predicibile (il vero tempo) zionamento interno del computer. mentre con il termine multitasking si intende unarchitettura software divisa in parti (dette processi o task) che vengono eseguite indipendentemente luna dallaltra; tale indipendenza per non assoluta ed Marco Aldrovandi maldrovandi@infomedia.it incontra il suo limite quando i vari processi devono condividere risorse comuni come ad esempio unarea laureato in Ingegneria Elettronica. Attualmente si occupa di di memoria, un canale di comunicazione o lo stesso applicazioni safety critical per il settore ferroviario. microprocessore. Chi progetta unarchitettura multita-

10

Computer Programming n. 146 - Maggio 2005

INFORMATICA

FIGURA 2

Architettura hardware della sonda

sking fa s che ciascun processo abbia un compito ben definito e diverso da quello degli altri processi: minore sar luso di risorse condivise, maggiore sar la frazione di tempo in cui i vari processi verranno eseguiti contemporaneamente luno allaltro, migliorando lefficienza complessiva del sistema. In Figura 2 viene mostrata larchitettura hardware della sonda Pathfinder: la CPU connessa ad un bus VME, al quale sono anche collegate direttamente la radio e lapparecchio per le riprese; il bus VME anche collegato ad un altro bus 1553 al quale sono a loro volta collegate la parte dedicata alla navigazione spaziale (cruise stage) e quella per latterraggio e le attivit al suolo (lander). Per essere utilizzato, il bus 1553 necessitava di un processo per la pianificazione (scheduling) delle attivit su di esso e di un altro processo per la distribuzione dei dati ai vari dispositivi utilizzatori. Come mostrato in Figura 3, lo scheduling doveva avvenire con una frequenza di 8 Hz, cio ad intervalli di 125 millisecondi.

essere letto e scritto da ogni processo e ha due stati: risorsa libera e risorsa occupata. Se un processo ha necessit di utilizzare la risorsa condivisa, legge il mutex e, se lo stato risorsa libera, lo cambier in risorsa occupata e inizier ad utilizzare la risorsa; se invece lo stato risorsa occupata, significa che un altro processo sta utilizzando la risorsa e al processo richiedente rimangono due scelte: rinunciare per riprovare successivamente oppure bloccarsi e mettersi in attesa che la risorsa si liberi... a questo punto i paragoni che possono essere fatti con molte situazioni della vita degli esseri umani vengono lasciati al lettore. La non disponibilit di una risorsa condivisa non lunica causa che pu bloccare un processo e metterlo in stato di attesa: ad un qualunque istante, il sistema operativo pu decidere che venuto il momento di fare eseguire un processo pi prioritario e quindi togliere al processo in esecuzione la risorsa pi preziosa, vale a dire il microprocessore: questa azione viene detta preemption ed i sistemi operativi che la attuano si dicono preemptive. Il fatto che un processo sia pi prioritario di un altro, non significa necessariamente che lattivit da esso svolta sia pi importante ma, dovendo assicurare un certo tempo di reazione (sistema real-time), non pu essere fermato da altri processi per pi di un certo tempo trascorso il quale il sistema operativo sospende il processo meno prioritario per occuparsi di quello con priorit maggiore. Se un sistema operativo invece non preemptive, lascer eseguire ogni processo fino a quando questo non si sospender spontaneamente lasciando modo agli altri di utilizzare il microprocessore.

Stato di attesa
Il processo di raccolta dei dati metereologici (processo ASI/MET) ed il processo di distribuzione dati sul bus 1553 comunicavano tramite un meccanismo messo a disposizione dal sistema operativo detto IPC (Inter Process Communication). Per assicurarsi che un solo processo per volta utilizzasse il canale, fu utilizzato un servizio del sistema operativo detto mutex (da mutua esclusione). Il mutex pu essere associato ad una risorsa condivisa, pu

FIGURA 3

I processi per la gestione del bus 1553

Computer Programming n. 146 - Maggio 2005

11

primo piano

FIGURA 4

Linversione di priorit

Inversione di priorit
Nella sonda Pathfinder, il processo ASI/MET aveva priorit bassa mentre quello dedicato a distribuire i dati del bus 1553 aveva priorit alta. I tecnici del JPL lasciarono funzionare il computer della sonda per molti giorni, non riuscendo a risimulare lo strano comportamento che si stava osservando su Marte, fino a quando and in reset anche il computer sulla Terra e, dai dati registrati, si scopr che la causa era molto particolare: poteva accadere una successione di eventi come quella mostrata in Figura 4: il processo ASI/MET utilizza il canale dati IPC mettendolo dunque in stato di risorsa occupata usando il mutex. Prima che il processo ASI/MET abbia il tempo di liberare il canale, il sistema operativo attua una preemption sospendendolo per fare eseguire processi pi prioritari. Per la stessa ragione, ad un certo punto viene sospeso il processo in esecuzione perch venuto il momento di fare eseguire quello dedicato alla distribuzione dei dati del bus 1553. Tale processo necessita per di utilizzare il canale IPC e quindi, trovandolo occupato, si sospende nuovamente, facendo riprendere lesecuzione del processo a media priorit prima sospeso. Quando viene fatto eseguire il processo ad alta priorit dedicato allo scheduling delle attivit sul bus 1553 (sono scaduti i 125 millisecondi), esso trover che il processo di distribuzione dati non ancora terminato: il sistema di autodiagnosi interpreta questo come funzionamento non ammissibile e dunque comanda il reset del computer osservato da Terra. 12

Comportamenti come questo vengono detti inversione di priorit: infatti un processo a bassa priorit (il processo ASI/MET) tiene bloccato un processo ad alta priorit (il processo di distribuzione dati). Nei sistemi operativi multitasking questo problema ben noto e viene risolto facendo ereditare le priorit: in un caso come quello prima citato, il processo a bassa priorit eredita temporaneamente lalta priorit del processo che sta bloccando, allo scopo di sbloccarlo prima possibile. Il sistema operativo usato sulla sonda Pathfinder poteva realizzare questa ereditariet, ma tale funzione era stata disabilitata in quanto ritenuta fonte di un inutile aumento di complessit del sistema: molto pi difficile infatti prevedere in modo rigoroso i tempi di risposta di un sistema nel quale le priorit dei processi possono variare nel tempo. Ora che la probabile causa era stata individuata, rimaneva da risolvere un piccolo problema: come cambiare questa impostazione in un computer che si trovava a milioni di chilometri di distanza. Il problema fu risolto grazie alla possibilit di trasmettere un nuovo software da Terra. Una volta eseguito lintervento, il problema cess di presentarsi. Pur essendo avvenuto in un contesto particolarissimo, questo caso presenta molti spunti di riflessione per i normali programmatori terrestri: si pu cio pensare a cosa ha reso pi facile lindividuazione di un problema cos sfuggente e cosa ne ha reso possibile la correzione anche in una situazione estrema; infine, e questa la parte pi difficile, si pu anche riflettere su cosa ha causato il problema.

Simulazione e registrazione
Senza dubbio, il problema non sarebbe stato individuato se non fossero stati disponibili una macchina esattamente uguale presente in laboratorio; un completo sistema di registrazione di tutto quanto avveniva allinterno del sistema, fino ad arrivare allo stato di ogni processo in ogni istante. Chiunque abbia installato un sistema software gestionale o una macchina automatica presso un cliente sa quanto siano importanti le risorse sopra elencate; se si vuole stabilire un ordine di importanza, la seconda risulta anche pi importante della prima: corredare la propria applicazione di un completo e dettagliato sistema di registrazione (logging) degli eventi risulta anche pi importante di poter disporre di un sistema gemello sul quale tentare di risimulare il comporta-

Computer Programming n. 146 - Maggio 2005

INFORMATICA
mento anomalo riscontrato sul campo, in quanto esistono stimoli esterni e situazioni particolari che sono difficili o addirittura impossibili da simulare in laboratorio, soprattutto se si tiene conto che non si sa qual la situazione che origina il problema. Un sistema di logging pu anche essere tenuto sempre attivo sul campo, dove pi probabile che il comportamento anomalo si ripresenti. Naturalmente, vi sono controindicazioni e precauzioni da prendere: un sistema di logging interno rischia infatti di degradare le prestazioni del sistema aumentando troppo i tempi di risposta. Una possibile soluzione pu essere quella di realizzare un sistema di logging normalmente disabilitato ma abilitabile nel caso si debba investigare su un comportamento anomalo; questo tipo di soluzione introduce per una variazione nel sistema sotto esame e pu causare anche il non ripresentarsi del problema mentre il sistema di logging abilitato. I bug software che hanno la spiacevole caratteristica prima citata vengono detti Heisenbugs, dal noto principio di indeterminazione di Heisemberg. Ove possibile, la soluzione migliore quella di predisporre un sistema di logging esterno, quale ad esempio uno sniffer su una linea di comunicazione: esso pu essere tenuto sempre attivo e non altera minimamente le prestazioni del sistema (se si trascurano gli effetti quantistici...); una soluzione del genere non per applicabile per registrare il comportamento del sistema operativo. costose; in questi casi, disporre di un sistema gemello dimostra tutta la sua necessit.

Accessibilit
Aver scoperto la causa del problema nella sonda Pathfinder sarebbe stato assolutamente inutile se non ci fosse stato modo di correggerlo. In questo caso, stato determinante poter disporre di un sistema con un elevato grado di accessibilit. Moltissime attivit che in laboratorio sembrano immediate, come ad esempio il cambiamento di un parametro di configurazione o la programmazione di un componente, sul campo possono risultare assolutamente impossibili o per la mancanza di un certo strumento o semplicemente perch non al momento disponibile una presa di corrente. Tra le tante, si consideri ad esempio proprio lattivit svolta da Terra verso la sonda Pathfinder, cio il caricamento e lesecuzione di software. Nel caso delle applicazioni realizzate per PC ormai prassi comune scaricare dal sito internet della software-house i programmi correttivi (patches) che, solitamente, sono auto-installanti. Anche in questo caso per vi possono essere problemi di sicurezza, legati alla certificazione dellautenticit della patch. Per le applicazioni embedded, tutto pi difficile: il software pu essere memorizzato su un componente programmabile, ed esempio una EPROM, per accedere alla quale occorre smontare parzialmente o totalmente talune parti meccaniche e, daltra parte, facilitare laccesso pu significare maggiore debolezza agli urti e ad altri fattori ambientali come pioggia e polvere. Il progetto deve essere quindi orientato anche a facilitare la soluzione dei problemi che si presentano dopo linstallazione (post-shipment problems).

priorit possono contendersi una risorsa


Come al solito quindi, la via migliore quella del compromesso: logging esterno dovunque possibile e logging interno ove necessario. Il caso della sonda Pathfinder fornisce per una ulteriore possibilit: si deve considerare infatti che il sistema di logging interno che ha consentito di individuare linversione di priorit sulla sonda gemella al JPL era installato e funzionante anche sulla sonda presente su Marte: lunica differenza era che la sonda Marziana non poteva, data la distanza, inviare i dati di logging a terra. Sulle due sonde vi era dunque lo stesso software e i tecnici del JPL erano quindi sicuri che, sulla sonda a Terra, vi sarebbero stati gli stessi tempi di elaborazione di quella su Marte, dunque nessun rischio di Heisenbugs (da qui la famosa massima test what you fly and fly what you test). Nel caso dei sistemi safety-critical, il cliente deve immediatamente disattivare il sistema in caso di comportamento anomalo e riattivarlo solo quando viene trovata e dimostrata la soluzione oppure, nel migliore dei casi, le possibili prove sul campo sono poche e

Processi di diversa

Programmazione difensiva e robustezza


Nonostante il problema dei reset ripetuti, non vi fu perdita di dati: lunico danno fu un ritardo di un giorno nella raccolta dei dati ogni qualvolta si verificava un reset. Se non fossero state implementate tecniche di programmazione difensiva come quella presente nel processo di scheduling (controllare cio che il processo di distribuzione dati avesse terminato lesecuzione) le conseguenze sulla missione sarebbero state molto peggiori. Il controllo effettuato dal processo di scheduling pu essere visto come una pre-condizione alla propria esecuzione. importante quindi individuare le pre-condizioni e le post-condizioni ed implementare controlli adeguati: questa tecnica prende il nome di assertion programming e, per il software safety-related, raccomandata dalla norma Europea 61508-3 (si veda anche [1] e [4]). Quando le batterie della sonda Pathfinder si esaurirono 3 mesi dopo latterraggio, la sonda era riuscita ad inviare a Terra ben 17000 immagini. I progettisti di Pathfinder avevano realizzato un software robusto, dove per robustezza si intende capacit di mantenere un comportamento accettabile anche in corrispondenza di situazioni non specificate nei requisiti ([3]). 13

Computer Programming n. 146 - Maggio 2005

primo piano

FIGURA 5

Condizioni di test: il caso migliore e quello reale

prioritaria rispetto ad altre attivit: tale scelta, a posteriori, non pu che essere considerata positivamente visto il successo della missione. Purtroppo per questo non sempre vero e chiunque si sia occupato di test sa che quel fastidioso e sfuggente difetto che si presentato una sola volta in laboratorio e che non si pi riusciti a risimulare (definito, in gergo, fantasma) si ripresenter sicuramente dopo linstallazione in impianto. In questo caso, lunica possibile difesa installare un sistema robusto (magari con programmazione difensiva) e progettato pensando ai post-shipment problems, come ben sapevano i progettisti di Pathfinder.

Il ruolo del testing


utile chiedersi come mai le estensive attivit di testing svolte a Terra prima del lancio non avessero messo in risalto il problema. A questo proposito, ci sono due punti importanti da evidenziare: il motivo non stava nella procedura ma nelle condizioni di test; in realt, il problema del reset si era presentato. Durante le fasi di test, le varie funzionalit della sonda erano state provate simulando un certo carico di lavoro originato da stimoli esterni; in particolare, era stato immaginato un certo flusso di dati per i processi di comunicazione nel migliore dei casi (best case). In realt, la missione and meglio delle pi rosee previsioni e la quantit di dati fu molto superiore (best-best case). In Figura 5 si pu vedere la differenza tra i due casi: nel best-best case i processi di comunicazione prendono pi tempo e dunque si presenta il problema dellinversione di priorit.

Conclusioni
Il caso della sonda Pathfinder pu essere visto come un esempio estremo della situazione in cui si ha un problema su una macchina o un impianto al quale non si pu accedere direttamente. Si visto che problemi del genere non possono essere risolti se non si dispone di una sufficiente quantit di informazioni su quanto accaduto o sta accadendo e se non possibile agire a distanza in modo da risolvere il problema. Tali requisiti devono essere assolutamente considerati in fase di progetto. Grande attenzione deve poi essere riservata alle condizioni di test, spesso testare un sistema anche al di sopra dei requisiti previsti rappresenta un costo aggiuntivo trascurabile ma pu mettere in risalto problemi che diversamente sarebbe difficile individuare o che, in condizioni di test pi leggere, si presentano sotto forma di fantasmi.

BIBLIOGRAFIA & RIFERIMENTI


[1] Marco Aldrovandi, Le attivit di testing per il software safety-related, Computer Programming 133 Marzo, Infomedia, 2004. [2] Steve March, Learning from Pathfinders Bumpy Start, Software Testing & Quality Engineering, September/October 1999, www.stqemagazine.com [3] A. Fuggetta, C. Ghezzi, S. Morasca, A. Morzenti, M. Pezz, Ingegneria del software - progettazione, sviluppo e verifica, Mondadori Informatica, 1999. [4] IEC International Standard 61508-3, Functional safety of electrical/electronic/programmable electronic safety- related systems - Part 3: Software requirements. [5] Michael Jones, Pathfinder debugging, http://www.kohala.com/start/papers.others/pathfinder.html [6] Glenn Reeves, What really happened on Mars, http://research.microsoft.com/~mbj/Mars_Pathfind er/Authoritative_Account.html

contro i post-shipment problems

Logging e accessibilit

Linsegnamento che si pu trarre da questo che occorre fare estrema attenzione alle condizioni di test: una volta creato lambiente di collaudo, aumentare il carico elaborativo simulato ha di solito un impatto economico trascurabile ma pu dare informazioni molto utili. Durante i test comunque si osserv qualche caso di reset ma lindagine venne ritenuta meno 14

Computer Programming n. 146 - Maggio 2005