Upload
gabriella-dodero
View
95
Download
3
Embed Size (px)
DESCRIPTION
Presentazione tenuta il 3.10.2014 nell'ambito dell'iniziativa di orientamento alle materie scientifiche MINT, organizzata dalla provincia Autonoma di Bolzano presso Sheraton Bolzano Fiera. Erano presenti oltre 300 studenti e i rispettivo docenti delle scuole superiori.
Citation preview
Quando i computer non funzionano -
su Marte Gabriella Dodero
3.10.2014
Sommario
1.Esplorazioni su Marte2.La missione del Pathfinder
a)Problemi su Marte, e b)Soluzione dei problemi
3.La teoria che c'e` dietro4.Cosa abbiamo imparato
Esplorazioni su Marte 1I primi tentativi di esplorare Marte risalgono agli anni '60"Gara" tra URSS e USA 1964: Mariner 4 riesce ad entrare nell'orbita di Marte, e rimanda sulla Terra 21 immagini
Esplorazioni su Marte 2
Anni 90: missione Viking (MOLTO costosa!!)1996: nuovo programma della NASA: il programma Discovery.
A costi relativamente bassi (meno di 150 M $) e con tempi di sviluppo delle missioni relativamente veloci
(meno di 3 anni)
La missione Pathfinder 1● L'obiettivo e` inviare un "rover" (veicolo senza
pilota) ad esplorare la superficie di Marte● Scopo principale: studiare la geologia del
pianeta, analizzare la composizione chimica del terreno e delle rocce.
● Scopo secondario: analizzare l'atmosfera e gli eventi meteorologici
● Nuova discesa "soft"
La missione Pathfinder 2
● E' possibile discendere "dolcemente" su Marte grazie ad una combinazione di paracadute ed air-bag
La missione Pathfinder 3
● Il razzo vettore Delta II parte da Cape Canaveral il 4 Dicembre 1996
La missione Pathfinder 4
L'attrezzatura inviata su Marte e` composta da:● Mars Pathfinder Lander: conteneva una
videocamera e una stazione meteo, e rappresentava il "garage" del rover
● Sojourner: il rover, che doveva "andare in giro" ad esplorare la superficie del pianeta
Sojourner – appena arrivato●
Sojourner in movimento
Se i computer non funzionano su Marte
● Discesa perfetta !! ● Iniziano i test scientifici, ma subito c'e` un
problema: ● Il software del Sojourner compie un reset !! Piu`
volte di seguito !!● Il reset fa ripartire correttamente il software, ma
nessuno riesce a capire come mai, e come far smettere i continui reset
● I dati non vanno perduti nel reset, ma bisogna rimandare gli esperimenti al "sol" (giorno marziano) successivo – per sempre?
Soluzione (trovata sulla Terra) ● I tecnici del JPL iniziano a lavorare su un
sistema "gemello" rimasto sulla Terra● Il software del Sojourner consente di lavorare in
modo "debug" ● Lanciando il programma in modo "debug", il
problema viene individuato: e' un problema di inversione di priorita`
● Per correggerlo, i tecnici sviluppano una "patch" e la inviano al Surveyor
Avviso importante !!!
● Se vi interessa solo la storia, potete saltare direttamente alla fine della presentazione
● Adesso infatti inizia una parte un po` piu` tecnica, in cui verra` illustrato il problema, e la soluzione trovata
Hardware su Marte
L'hardware del Sojourner era gestito da una sola CPU
● Un bus collegava le due parti del veicolo spaziale, ● Lo stadio di crociera, che conteneva un sensore
solare e uno scanner stellare● Lo stadio di atterraggio, che conteneva un altimetro
radar e una stazione meteo● Le interfacce del bus, riutilizzate da una
missione precedente, schedulavano le attivita` con una frequenza ciclica di 8 Hz
Architettura del sistema
Schedulazione del bus ● La raccolta dati dal bus era affidata a due task:
● Il gestore delle transizioni del bus (bc_sched)● Il responsabile di acquisizione dati (bc_dist)
● Una sequenza di operazioni corrette richiedeva che i due task si alternassero in esecuzione, durante ogni ciclo di 8Hz● Quando un task iniziava, per prima cosa controllava
che l'altro task avesse finito; altrimenti, generava un reset del sistema.
Ciclo di esecuzione
Ciclo eterno:1.Attivazione del bus hardware2.Quando la trasmissione sul bus e' conclusa, parte
bc_dist 3.Quando bc_dist ha distribuito i dati, termina e parte
a sua volta bc_sched4.Il task bc_sched imposta le transizioni del ciclo
successivo, quindi termina
Operazioni di bc_sched
In ogni ciclo, bc_sched determina quali azioni (task) devono essere eseguite al ciclo successivo
● La scelta dei task dipende dalla rispettiva priorita`, e all'avvio, ciascuno di essi "trova" in un buffer interno i dati di cui ha bisogno
● Tali dati sono ricuperati da bc_dist durante il ciclo precedente
● Fa eccezione il task meteo station, che comunica direttamente con bc_sched
Priorita` dei task sul Rover
Le priorita` dei task, in ordine decrescente, sono:1.bc_sched2.Task di discesa (non piu` attivo dopo l'atterraggio)3.bc_dist4.Task relativi alle operazioni della stazione spaziale 5.Tasks relativi agli esperimenti scientifici (tra cui
compressione delle immagini e interfacciamento della stazione meteo)
I task vengono eseguiti in modo preemptive ● Ogni task sospende tutti gli altri task di priorita`
inferiore!
Ma perche` il computer non funzionava su Marte?
Il problema riguardava tre task:● bc_dist (priorita` 3), ● Un qualsiasi task relativo alle operazioni della stazione
spaziale (priorita` 4), e ● Il task della stazione meteo (priorita` 5)
Il task della stazione meteo riceveva i dati da bc_sched, per fare questo, doveva prendere in uso esclusivo (lock) una risorsa, cioe` il bus.
● La sua esecuzione veniva sospesa dal task con priorita` 4, prima che rilasciasse il lock,
● Successivamente, bc_dist non riusciva ad acquisire quella risorsa, e forzava il reset.
Schema dell' inversione di priorita`
La soluzione - 1● Quando il task a priorita` piu` bassa acquisisce un
lock, esso deve essere eseguito a priorita` maggiore ● In questo modo il task a priorita` intermedia non puo`
sospenderlo!!!
● Il problema di inversione di priorita` in questo modo viene risolto
● La patch che cambiava la priorita` venne sviluppata ed inviata su Marte, aggiornando cosi` il software del rover
La soluzione - 2● Il problema di inversione di priorita` non era per nulla
nuovo● Era stato studiato da tempo nella teoria dei Sistemi
Operativi, ● Il software che gestiva questo scambio di priorita`
era in effetti gia` presente sul rover, ma non venva eseguito per motivi di efficienza,
● La patch sostanzialmente si limitava a riattivarlo!● I test svolti sulla Terra prima del decollo non avevano
mostrato la necesita` di attivare questo software!● Su Marte, il bus raccoglieva piu` dati del previsto, e le
operazioni dei task avevano durate superiori
Il lieto fine ● La patch funziono` perfettamente, e non ci furono piu`
reset.● Il rover continuo` a funzionare per diversi mesi
(l'aspettativa iniziale era di una sola settimana!)● L'ultimo collegamento con la Terra fu il 27.09.1997
E poi ...● Il Mars Orbiter "Reconnaissance" scatto` alcune
immagini ad alta definizione della superficie di marte nel 2007, in cui si vede ancora il Pathfinder
Cosa abbiamo imparato ?● La legge di Murphy vale anche su altri pianeti
● Mai ignorare una "teoria", anche se riguarda eventi improbabili!
● E' meglio eseguire operazioni "corrette" piuttosto che operazioni "veloci"
● Il software per "debugging" e` importante, e spesso indispensabile, per riuscire a gestire situazioni impreviste
Secondo voi, questa storia rappresenta un successo o un fallimento ?
Pronti al decollo ... ?