Gli editoriali di Byte Italia

Fattore critico

Byte Italia n° 17 (inedito)

Una volta mi fidavo dei computer.

In realtà mi fido abbastanza di loro anche oggi, almeno in determinate situazioni; tuttavia l'idea che ormai vi siano microcomputer in quasi tutti i dispositivi elettronici, e che questa proliferazione di automatismi "intelligenti" basati su microprocessori embedded non sia destinata a diminuire ma, anzi, ad estendersi, inizia a preoccuparmi un po'.

"Uffa", dirà qualcuno, "la solita tiritera contro l'inaffidabilità dei PC, le solite rievocazioni nostalgiche di quanto si stava meglio col DOS o l'Apple II e 64K di RAM". No, tranquilli. Questa volta non me la prendo coi PC, che oramai è diventato come sparare sulla Croce Rossa. Me la prendo invece con un fenomeno decisamente più ampio e fondamentale ma stranamente meno dibattuto, e quindi a mio avviso più preoccupante.

Il problema vero è nel software, o meglio nei modelli e nei paradigmi dello sviluppo del software, che ancora oggi mi sembrano drammaticamente primitivi. Diciamocelo francamente: in cinquant'anni di informatica il modo di fare il software non è poi cambiato così tanto. La programmazione strutturata è invenzione degli anni '80, e ancora quindici anni fa si dibatteva se il GOTO fosse un'istruzione accettabile o no. La successiva programmazione ad oggetti, che sembrava finalmente in grado di allineare lo sviluppo del software agli stessi standard industriali utilizzati per la produzione di componenti fisici, dopo dieci anni ha sconsolantemente dimostrato tutti i suoi limiti.

E così fare software è ancora largamente un'arte, non un processo industriale. E cose quali il rispetto delle specifiche, l'effettuazione delle procedure di verifica ed il testing, l'applicazione dei controlli di qualità, si svolgono spesso in maniera artigianale o comunque senza il rigoroso ricorso a metodologie formali ed automatiche, per il semplice motivo che queste di fatto non esistono. D'accordo, forse esagero: diciamo allora che esistono alcune metodologie a livello essenzialmente accademico, la cui attuazione pratica lascia spesso a desiderare, e che comunque non eliminano del tutto i soliti vecchi problemi che affliggono lo sviluppo del software sin dall'era di Von Neumann.

In tutto ciò vedo una serie di problemi concettuali. Ad esempio, forse è proprio sbagliato considerare il software come un oggetto industriale. Il software tutto sommato non è e non si comporta come un meccanismo fisico, e quindi dovrebbe essere progettato e verificato in modo diverso. Ma di questo nessuno sembra rendersi conto a fondo. I meccanismi di autoprotezione di ogni dispositivo fisico, ad esempio, sono fatti per salvaguardare la funzionalità e la stabilità del dispositivo stesso in seguito ad errori casuali provocati durante il suo funzionamento da eventi esterni accidentali ed imprevedibili. Il software invece fallisce per colpa di errori sistematici, non di fluttuazioni casuali (il valore di una variabile non cambia da solo!) e dunque i meccanismi di verifica e correzione, così come quelli di gestione delle eccezioni, dovrebbero essere fondamentalmente diversi da quelli impiegati nell'hardware. Tanto per dirne una, non basta duplicare un sottosistema nella speranza di migliorarne l'affidabilità, se nelle due copie gira esattamente lo stesso software! La ridondanza protegge infatti contro malfunzionamenti casuali, ma un errore sistematico nel software stesso metterà certamente fuori uso entrambe le copie del sottosistema, con buona pace della duplicazione.

Dico cose banali? Forse. Tuttavia il fallimento nel 1996 della prima missione dell'allora nuovo vettore europeo Ariane 5, che esplose in aria a 37 secondi dal decollo con il suo preziosissimo carico di satelliti scientifici, si è verificato proprio per un banale errore nel software di controllo delle piattaforme inerziali, scritto in Ada, che nessuna procedura di verifica e controllo aveva rilevato. E la ridondanza delle piattaforme non ha potuto fare nulla per evitare il disastro.

E proprio poche settimane fa la sonda Mars Climate Orbiter della NASA si è probabilmente schiantata sul pianeta rosso perché nessun software di verifica e nessuna procedura di controllo si erano accorti che i due team di controllo della missione avevano usato l'uno le unità di misure metriche e l'altro quelle anglosassoni nel calcolare i dati relativi all'orbita, col risultato di inviare al veicolo delle istruzioni d'assetto completamente assurde nella fase critica di avvicinamento al pianeta.

A questo punto mi domando: ma il software che gestisce la centralina elettronica delle nostre autovetture, come è stato scritto? E come facciamo ad essere sicuri che un giorno o l'altro non ci si bloccherà l'ABS in curva o non ci esploderà in faccia l'airbag in galleria per un "banale" errore di programma?

Ultima modifica: 4 settembre 2006
Visitatori dal 6 maggio 2003: 113,555

Torna alla Pagina degli editoriali di Byte Italia
Vai alla Pagina dei Commenti