Lancio dello shuttle x il 7 Dic.x paura cambiamento data pc di bordo

Fonte New York Times :

Vogliono lanciare lo shuttle il 7 Dicembre per paura del cambiamento della data dei computer di bordo,se dovesse partire qualche settimana dopo…e cosi arrivare al capodanno…
Di seguito l’articolo del NYT

CAPE CANAVERAL, Fla., Nov. 9 (AP) — The space shuttle Discovery was moved to the launching pad on Thursday to await a liftoff that could be as early as Dec. 7, an effort to avoid potential New Year’s Eve computer glitches.

The worry is that shuttle computers are not designed to make the change from the 365th day of the old year to the first day of the new one while in flight. NASA has never had a shuttle in space on Dec. 31 or Jan. 1.

“We’ve just never had the computers up and going when we’ve transitioned from one year to another,” said Joan E. Higginbotham, a Discovery astronaut. “We’re not really sure how they’re going to operate.”

Launching opportunities would be available from Dec. 7 to as late as Dec. 17 or 18, for a 12-day mission.

But NASA was quick to say that procedures could be devised to make a transition if necessary.

“If we have an ‘Oh my God,’ and we have to be up there, I am sure we would figure out a way to operate the vehicle safely,” said Steve Oswald, a vice president for Boeing, the parent company of the builders and designers of the shuttles.

Ohmammamia, ma che paranoie… :scream:

Basisco!! :? :scream:

Vabbhè che la dose massima consentita di “erba” è stata raddoppiata ma questi “fumano” dei prati … :scream:

Qui mi sa che bisogna ricorrere al più presto al testicula tacta del testicula tacta :scream:

Voila’, ogni tanto leggo e posto ancora :smiley:
Scusate ma fuori dalle missioni importanti ho pochissimo tempo per il forum.

Non la vedo come una paranoia…pensate che i computer di volo sono ancora con tecnologia degli anni 70.
(la rimodernizzazione degli anni 90 ha influito principalmente sui sistemi della cabina, credo, ma in gran parte sono solo modifiche “di facciata”…meno tubi catodici e schede perforate insomma :slight_smile: )

Parlando nello specifico del software, scommetto che buona parte di quel sw e’ in Assembler per processori magari un po’ esotici e qualche cosina in alto livello credo in ADA (http://en.wikipedia.org/wiki/Ada_(programming_language))

Diverso e’ dire “non sappiamo se ci sarebbero dei problemi” e “non possiamo sapere se ci sarebbero dei problemi”.
Un analisi di codice vecchio, seppure credo ben documentato (in un ambiente come la NASA dove ogni bullone ha un codice univoco), sarebbe un impresa titanica, specie nel momento in cui non si sa bene cosa cercare.

Un noto teorema dell’informatica (noto al punto che non ne conosco il nome :slight_smile: ) dice che non e’ possibile dimostrare l’assenza di bug.

In questo caso, non e’ possibile neanche raggiungere un ragionevole livello di confidenza.

Un noto teorema dell'informatica (noto al punto che non ne conosco il nome :) ) dice che non e' possibile dimostrare l'assenza di bug. In questo caso, non e' possibile neanche raggiungere un ragionevole livello di confidenza.

Intanto piacere di risentirti :smiley:
Devo dire che la mia esclamazione era dovuta comunque all’incredibile ricorrenza di queste “scoperte”: ma come, lo shuttle vola dal 1981 e mi si viene a dire che al tempo della progettazione nessuno aveva previsto eventuali problemi per missioni che si svolgessero a cavallo tra anni diversi?
Lo stesso dicasi per attuatori montati al contrario, bulloni troppo lunghi o corti, ecc ecc ecc, tutti problemi emersi dopo l’incidente del Columbia e che inspiegabilmente paiono essere sempre stati ignorati o non conosciuti prima di quel fattaccio.
Questo mi lascia perplesso.
D’altra parte, da informatico di professione, devo dire che realizzare un software suscettibile di problemi per il cambio dell’anno è quanto meno ridicolo: UNIX conta, per determinare una data, il numero di secondi trascorsi dal 1/1/1970. Si tratta di un semplice numero intero, che si incrementa di una unità ogni secondo. Facile, efficiente, rapido.
UNIX era certamente esistente al tempo della realizzazione dei SW dello shuttle. Non dico che si dovesse usare un tale sistema operativo, sia chiaro, ma quanto meno ispirarsi a quello che era (e per certi versi ancora è) un modello di eccellenza.

Da utente linux da 6 anni, FreeBSD per un breve periodo, e (Darwin)/MacOS oggi, non posso che essere d’accordo con il tuo discorso sull’efficienza e la relativa semplicita’ progettuale di questi gioelli dell’informatica :slight_smile:

Il problema tuttavia, non credo stia nel sistema operativo (che cmq sara’ senza dubbio di tipo realtime (anche se non so quanto la distinzione fosse netta negli anni 70-80, non sappiamo nemmeno a quale sistema si riferiscano, magari sono sistemi dedicati dove il SO coincide con l’“applicativo”)) quanto nel comportamento dei vari programmi.
Sono milioni di righe di codice scritte da centinaia di persone…ipotizziamo che il sistema conti i secondi dall’inizio dell’anno e resetti a zero alla fine (improbabile, ma e’ per fare un esempio).
John Smith, neo laureato al MIT, ma con scarsa esperienza, e’, per qualche ragione, incaricato di scrivere una parte di codice che ha un controllo del tipo: “se e’ passato piu’ di un secondo, alza il pin di controllo 42”.

In C (perche’ mi vien comodo, la sintassi ADA l’ho rimossa il secondo dopo aver consegnato l’unico esame in cui era stata utilizzata :), ma supponi che questa cosa sia nel ciclo di attesa di un task in ADA, in un sistema a timesharing) Jonh scrive:

old_seconds = newseconds;
newseconds = get_year_seconds();

if( newseconds>oldseconds )
raise_signal(42);

John compila tutto in una libreria, da al suo capo, e 3 mesi dopo parte il Columbia per la STS-1

Tutto va per il meglio e il programma shuttle continua per altri 23 anni.

A mezzanotte UTC, newseconds passa da 31.536.000 a 0.
Il controllo fallisce, il segnale rimane basso, l’attuatore non si muove, BOOM!! :slight_smile:

il tutto e’ moooolto ipotetico, e ci si potrebbe chiedere perche’ un neolaureato ha scritto del codice senza supervisione, ma era una piccola libreria, in un piccolo sottoprogetto, di un enorme sistema…puo’ capitare.

Ed e’ un esempio di problema che non solo non e’ testabile a terra, ma e’ anche difficile da scovare, in codice certificato che ha fatto il suo lavoro per quasi un quarto di secolo.

Quindi non ci sono mai state missioni Shuttle a cavallo dell’anno?

Ed e' un esempio di problema che non solo non e' testabile a terra, ma e' anche difficile da scovare, in codice certificato che ha fatto il suo lavoro per quasi un quarto di secolo.

Grazie per la tua chiarezza.
Condivido quanto hai scritto, ma devo dire che, terra terra, non credo sarebbe così impossibile “postdatare” un computer dello shuttle e vedere che succede al cambio di anno.
Ovviamente le mie sono solo ipotesi da ignorante, :stuck_out_tongue_winking_eye: potrei aver detto una grandissima caxxata, ma spero emergano approfondimenti sulla questione che è insieme disarmante e interessante.

Ma guarda Admin che sono molto piu’ ignorante di te!
Cercavo solo di approcciare il problema in un modo un po’ diverso da come fa la stampa di settore!

Mi vengono in mente 2 ragioni diverse perche’ potrebbe non essere possibile testarlo in orbita.

  1. tra le ipotesi di fallimento di un sistema ce ne e’ una “grave” a sufficienza da non voler rischiare
  2. il problema e’ in un sistema a livello molto basso, magari di pura telemetria, non comandabile da remoto.

Inoltre, potrebbe essere che semplicemente “non ci hanno mai pensato”.

Hai mai acceso il fendinebbia della tua macchina nuova prima di un giorno di nebbia “solo per provarlo”? :smiley:

Inoltre, potrebbe essere che semplicemente "non ci hanno mai pensato".

Giusto tutto quanto hai detto.
L’affermazione che cito è quella che sotto sotto, mi inquieta come un presentimento… :roll_eyes:

Beh, il “non ci hanno mai pensato” e’ riferito a un test (ipotizzando che sia NECESSARIO svoglerlo in orbita) di quei sottosistemi che generano dubbi sul cambio di data.

Non e’ che durante la missione di, che ne so, deployment di Ulysses, viene in mente di inserire nella schedule al giorno 4 “test di cambiamento di data”…a meno che non si sia gia’ fatta una riunione in cui la questione e’ stata sollevata.

Una delle collocazioni possibili di questo test sarebbe stata una delle due missioni di return to flight, ma direi che avevano altro a cui pensare :wink:

Visto che lavoriamo per ipotesi, e le nostre conclusioni hanno la loro stessa, ipotetica, validita’, sarebbe interessante conoscere qualcuno che sia “dentro” il programma Shuttle e che possa confermare o smentire i nostri (soprattutto miei dal punto di vista tecnico) sproloqui :smiley: